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Abstract 

Onion Routing is an infrastructure for private com- 
munication over a public network. It provides anony- 
mous connections that are strongly resistant to both 
eavesdropping and traffic analysis. Thus it hides not 
only the data being sent , but who is talking to whom. 
Onion Routing’s anonymous connections are bidirec- 
tional and near real-time, and can be used anywhere 
a socket connection can be used. Proxy aware appli- 
cations, such as web browsing and e-mail, require no 
modification to use Onion Routing, and do so through 
a series of proxies. Other applications, such as remote 
login, can also use the system without modification. 
Access to an onion routing network can be configured 
in a variety of ways depending on the needs, policies, 
and facilities of those connecting. This paper describes 
some of these access configurations and also provides a 
basic overview of Onion Routing and comparisons with 
related work. * 1 

Keywords: Security, privacy, anonymity, traffic 

analysis. 

1 Introduction 

Preserving privacy means not only hiding the con- 
tent of messages, but also hiding who is talking to 
whom (traffic analysis). Much like a physical enve- 
lope, the simple application of cryptography within a 
packet-switched network hides the messages being sent, 
but can reveal who is talking to whom, and how often. 
Onion Routing is a general purpose infrastructure for 
private communication over a public network. It pro- 
vides anonymous connections that are strongly resis- 
tant to both eavesdropping and traffic analysis. The 
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connections are bidirectional, near real-time, and can 
be used for both connection-based and connectionless 
traffic. Onion Routing interfaces with off the shelf soft- 
ware and systems through specialized proxies, making 
it easy to integrate into existing systems. Prototypes 
have been running since July 1997. As of this article’s 
submission, the prototype network is processing more 
than 1 million Web connections per month. Connec- 
tions have come from more than thirty thousand IP 
addresses in more than sixty countries and in all six 
main top level domains [12]. 

Onion Routing operates by dynamically building 
anonymous connections within a network of real-time 
Chaum mixes [3]. 2 A mix is a store-and-forward device 
that accepts a number of fixed-length messages from 
numerous sources, performs cryptographic transforma- 
tions on the messages, and then forwards the messages 
to the next destination in a random order. A single mix 
makes tracking of a particular message either by spe- 
cific bit-pattern, size, or ordering with respect to other 
messages difficult. By routing through numerous mixes 
in the network, determining who is talking to whom is 
made even more difficult. Onion Routing’s network of 
core onion routers (mixes) is distributed, fault-tolerant, 
and under the control of multiple administrative do- 
mains, so no single onion router can bring down the 
network or compromise a user’s privacy, and cooper- 
ation between compromised onion routers is thereby 
confounded. The prototype network is entirely under 
our control and connections to it are not protected. 
Thus, the amount of protection is limited and subject 
to the trust of our administrative domain. However, 
arrangements are currently well under way for a net- 
work consisting of NRL controlled onion routers as well 
as onion routers controlled by independent commercial 
companies. By modifying entrance configurations and 
exit policies, Onion Routing is completely compatible 
with a wide variety of policies regarding resistance to 
traffic analysis and other security needs. This is de- 
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scribed below in section 5. 

2 Application Support via Proxies 

Onion Routing can be used with applications that 
are proxy- aware, as well as several non-proxy- aware ap- 
plications, without modification to the applications. 
Currently supported protocols include HTTP, FTP, 
SMTP, rlogin, telnet, NNTP, finger, whois, and raw 
sockets. Proxies are under development for Socks5, 
DNS, NFS, IRC, HTTPS, SSH, and Virtual Private 
Networks (VPNs). A proxy has three logical layers: 
an optional application specific privacy filter that san- 
itizes the data streams; an application specific layer 
that translates the data streams into an application in- 
dependent format accepted by the Onion Routing net- 
work; and lastly, an onion building layer that builds 
and manages the anonymous connections. Because it 
builds and manages the anonymous connections, the 
proxy is the most trusted component in the system. 
Also, to build onions and hence define routes the proxy 
must know enough about the topology and link state 
of the network, the public certificates of nodes in the 
network, and the exit policies of nodes in the network. 
This information is distributed securely within the net- 
work automatically as new nodes come on-line or as the 
information changes. 

3 Anonymous Connections 

Onion Routing’s anonymous connections are pro- 
tocol independent and exist in three phases: connec- 
tion setup, data movement, and connection tear-down. 
Setup begins when the initiator creates an onion, which 
defines the path of the connection through the net- 
work. An onion is a (recursively) layered data struc- 
ture that specifies properties of the connection at each 
point along the route, e.g., cryptographic control infor- 
mation such as the different symmetric cryptographic 
algorithms and keys used during the data movement 
phase. The onion is treated as a destination address 
by onion routers; thus, it is used to establish an anony- 
mous connection. Onions themselves appear differently 
to each onion router (OR) as well as to network ob- 
servers. (The same goes for data carried over the con- 
nections they establish.) Connection routes can tra- 
verse an arbitrary number of ORs. A single onion can 
set up a route of eleven hops. Longer routes require 
tunnelling of onions through a connection. Each OR 
along the route uses its public key to decrypt the entire 
onion that it receives. This operation exposes the cryp- 
tographic control information, the identity of the next 


OR, and the embedded onion. The OR pads the em- 
bedded onion to maintain a fixed size, and sends it to 
the next OR. After the connection is established, data 
can be sent in both directions. Data from the initiator 
is repeatedly pre-encrvpted using the algorithms and 
keys that were specified in the onion. As data moves 
through the anonymous connection, each OR removes 
one layer of encryption as defined by the cryptographic 
control information in the onion defining the route, so 
the data arrives as plaintext at the recipient. This 
layering occurs in the reverse order (using different al- 
gorithms and keys) for data moving backward. Con- 
nection tear-down can be initiated by either end, or in 
the middle if needed. 

All information (onions, data, and network con- 
trol) are sent through the Onion Routing network 
in uniform-sized cells. All cells arriving at an OR 
within a fixed time interval are mixed together to re- 
duce correlation by network insiders. Likewise, the 
longstanding connections between ORs can be padded 
and bandwidth-limited to foil external observers. An 
onion looks different to each OR along a connection 
because of the layered public-key cryptography. Simi- 
larly, the layering of symmetric cryptography over the 
data phase cells makes them appear different to each 
OR. This design resists traffic analysis more effectively 
than any other deployed mechanisms for Internet com- 
munication. 

4 Connection Overhead 

Onion Routing’s overhead is relatively small. Con- 
nection setup overhead is typically much less than one 
second and appears to be no more noticeable than other 
delays associated with normal Web connection setup 
on the Internet. Computationally expensive public-key 
cryptography is used only during this connection setup 
phase. Also, because public-key decryption is much 
more expensive than encryption, the public-key burden 
rests mainly upon the onion routers themselves, where 
the option of dedicated hardware acceleration can be 
justified. Our modular design is completely compatible 
with doing the public-key operations in either hardware 
or software, and we are using both in our test networks. 
(Aside: Because there is no cryptography in the sys- 
tem code itself, Onion Routing system code has already 
been approved for unlimited distribution.) 

The data movement phase uses only secret-key 
(symmetric) cryptography, which is much faster. Fur- 
thermore, since the symmetric encryption can be 
pipelined, data throughput can be made as fast as or- 
dinary link or end-to-end encryption. Data latency is 
affected by the number of ORs along the connection 



and can vary with route length and the duration of the 
mix cycles. 

5 Access Configurations and 
Exit Policies 

Proxies, onion routers, and other components can be 
run in a variety of distributed configurations. This al- 
lows Onion Routing to mesh well with a wide variety of 
operational and policy environments. We now consider 
some of these possibilities for access configurations. 

• Remote-Proxy Access 

At one extreme, proxies can run remotely. If a 
user makes an encrypted connection to a trusted 
remote proxy, Onion Routing’s protection can be 
utilized without installing any software or induc- 
ing local computational overhead. If the initiator 
can trust the remote proxy to build onions, his as- 
sociation with the anonymous connection from the 
first OR to the responder is hidden from observers 
and the network. In a similar way, an encrypted 
connection from an exit funnel (demultiplexor) to 
a responder hides the association of the responder 
with the anonymous connection. 

Therefore, if an initiator makes an anonymous con- 
nection to some responder, and layers end-to-end 
encryption over that anonymous connection, the 
initiator and responder can identify themselves to 
one another, yet hide their communication from 
the rest of the world. So, we can build virtual 
private networks without protected sites. 

Notice, however, that the initiator trusts the re- 
mote proxy to conceal that the initiator wants to 
communicate with the responder, and to build an 
anonymous connection through the OR network. 
The next paragraph describes how to shift some 
of this trust from a remote site to the initiator. 

• Customer-ISP Access 

Suppose, for example, an Internet Services 
Provider (ISP) runs a funnel (multiplexor) that 
accepts connections from onion proxies running on 
subscribers’ machines. In this configuration, users 
generate onions specifying a path through the ISP 
to the destination. Although the ISP would know 
who initiates the connection, the ISP would not 
know with whom the customer is communicating, 
nor would it be able to see data content. So the 
customer need not trust the ISP to maintain her 
privacy. Furthermore, the ISP becomes a com- 
mon earlier, who carries data for its customers. 


This may relieve the ISP of responsibility both 
for whom users are communicating with and the 
content of those conversations. The ISP may or 
may not be running an OR as well. If he is run- 
ning an onion router, then it is more difficult to 
identify connections that terminate with his cus- 
tomers; however, he is serving as a routing point 
for other traffic. On the other hand, if he sim- 
ply runs a funnel to an onion router elsewhere, it 
will be possible to identify connections terminat- 
ing with him, but his overall traffic load will be 
less. Which of these would be the case for a given 
ISP would probably depend on a variety of ser- 
vice, cost, and pricing considerations. Note that 
in this configuration the entry funnel must have 
an established longstanding connection to an OR 
just like any neighboring OR. In most other cases, 
where the funnel resides on the same machine as 
the onion router, establishing an encrypted long- 
standing connection should not be necessary since 
the funnel can be directly incorporated into the 
Onion Router. 

• Island-Unto-Yourself Access 

If one wants to gain the maximum protection af- 
forded by Onion Routing, it is necessary to have 
local control of an onion router. Assuming that 
this OR also serves as an intermediate node for 
routing of other traffic, not only data and route 
are hidden but also the time and volume informa- 
tion about connections originating or terminating 
locally. Of course this additional protection comes 
at the price of having adequate Internet band- 
width to function in this way. 

• Proxy-and-OR-at-Firewall Access 

When a proxy and onion router sit on the firewall 
of a sensitive site, they can serve as an interface be- 
tween machines behind the firewall and the exter- 
nal network. Connections from machines behind 
the firewall to the onion router are protected by 
other means (e.g., physical security). To compli- 
cate tracking of traffic originating or terminating 
within the sensitive enclave, this OR should also 
route data between other ORs. This configura- 
tion might represent the system interface from a 
typical corporate or government site. 

Connections between machines behind firewall 
ORs are protected against both eavesdropping and 
traffic analysis. Since the data stream never ap- 
pears in the clear on the public network, this data 
may carry identifying information, but communi- 



cation is still private. (This feature is used in con- 
structing VPNs via Onion Routing.) 

The onion router (more precisely the proxy) at the 
originating protected site knows both the source 
and destination of a connection. This protects the 
anonymity of connections from observers outside 
the firewall but also simplifies enforcement of and 
monitoring for compliance with corporate or gov- 
ernmental usage policy. 

The use of anonymous connections between two 
sensitive sites that both control ORs effectively 
hides their communication from outsiders. Also, 
by employing a layering of funnels and ORs within 
firewalls, enclaves can incorporate traffic analysis 
resistance to their defense-in-depth. 

• Local-Proxy-with-OR-at-Firewall Access 

It is possible to hide the route and origination of 
connections originating at an enclave while also 
protecting the route, application, and data being 
transmitted from enclave administrators. In this 
arrangement Onion Routing connected users are 
visible within the firewall, but not to where they 
are connected or what applications they are run- 
ning. 

The above discussion describes the various ways that 
a connection can enter an onion routing network. But, 
exiting is also important. Unless the responder of a 
connection is behind a firewall on which the terminal 
OR resides (e.g., if the responder is some arbitrary 
Web server) the data stream from the sensitive ini- 
tiator must also be anonymized to avoid exposing the 
initiator. For example, an external attacker could sim- 
ply listen in on the connections to a Web server and 
identify initiators of any connection to it. This point 
about exiting an OR network applies equally regardless 
of the configuration of entrance access. 

There are other issues concerning how a connection 
exits an OR network. Exit points can also set poli- 
cies for exiting based on where the traffic is going, and 
what application protocol is being run. Thus, for ex- 
ample, an onion router at a corporate firewall might 
allow anyone to attempt to remote login, but only to 
machines behind the firewall. It might allow email traf- 
fic to exit to any company site and Web traffic to exit 
to anywhere. Of course, these exit limitations might be 
a problem for the proxies attempting to create connec- 
tions if they did not have the policies available when 
attempting to build a route. 

There is a database engine attached to each of the 
onion routers. These ensure that any changes to this 
information propagates throughout the entire network 


to the proxies that construct routes. They also inform 
neighboring ORs about changes to network topology 
and link state, as well as ensuring that such informa- 
tion from others propagates throughout the network. 
In this way, proxies are given the most up-to-date in- 
formation possible about potential routes. This greatly 
reduces the chance of bad connections that would then 
have to be attempted again via another route. The 
system that generates and distributes this information 
can be configured to be just as flat as the network itself, 
and authentication is of the relevant exit point or onion 
router. Thus, there is much less danger of central fail- 
ure (or hostile manipulation) of this information. So, it 
is also more difficult to, e.g., manipulate this informa- 
tion to cause routes to pass through only compromised 
cooperating onion routers. 

6 Background and Comparisons 

As mentioned above, Chaum [3] defines a layered 
object that routes data through intermediate nodes 
(mixes). These intermediate nodes may reorder, de- 
lay, and pad traffic to complicate traffic analysis. In 
mixes, the assumption is that a single perfect mix ad- 
equately complicates traffic analysis, but a sequence of 
multiple mixes is typically used because real mixes are 
not ideal. Because of this, mix applications can use 
mixes in fixed order, and often do. Onion routers dif- 
fer from mixes in using an indeterminate number of 
mixes in an indeterminate order, and in at least two 
other ways: onion routers are more limited in the ex- 
tent to which they delay traffic at each node because 
of the real-time expectations that the applications de- 
mand of socket connections. Also, in a some Onion 
Routing access configurations, onion routers are also 
entry points to the onion routing network, and traffic 
entering or exiting at those nodes may or may not be 
visible to outsiders. This can make it hard to track 
packets, because they may drop out of the network 
at any node, and new packets may be introduced at 
each node. While Onion Routing cannot delay traffic 
to the extent that mixes can, traffic between ORs is 
multiplexed over a single channel and is link encrypted 
with a stream cipher. This makes it hard to parse the 
stream. 

Anonymous remailers like Penet [9] strip headers 
from received mail and forward it to the intended re- 
cipient. They may also replace the sender’s address 
with some alias, permitting replies. These sorts of re- 
mailers store sensitive state: the mapping between the 
alias and the true return address. Also, mail forwarded 
through a chain of remailers may be tracked because it 
appears the same to each remailer. 



Mix based remailers like [4, 8] use mixes to provide 
anonymous e-mail services. Essentially, the mail mes- 
sage is carried in the innermost layer of an onion-like 
data structure. Another onion-like structure, used for a 
return address, can be contained in the message. This 
makes the return path self contained, and the remailer 
essentially stateless. Onion Routing shares many struc- 
tures with Babel [8] but it uses them to build applica- 
tion independent end-to-end connections. This makes 
anonymous connections accessible to a wide variety of 
applications. 

In [10], mixes are used to provide untraceable com- 
munication in an ISDN network. Here is a summary 
of that paper. In a phone system, each telephone line 
is assigned to a particular local switch (i.e., local ex- 
change), and switches are interconnected by a (long dis- 
tance) network. Anonymous calls in ISDN rely upon an 
anonymous connection between the caller and the long 
distance network. These connections are made anony- 
mous by routing calls through a predefined series of 
mixes within each switch. The long distance endpoints 
of the connection are then mated to complete the call. 
(Notice that observers can tell which local switches are 
connected.) This approach relies upon two unique fea- 
tures of ISDN switches. Since each phone line has a 
subset of the switch’s total capacity pre-allocated to it, 
there is no (real) cost associated with keeping a phone 
line active all the time, either by making calls to itself, 
to other phone lines on the same switch, or to the long 
distance network. Keeping phone lines active compli- 
cates traffic analysis because an observer cannot track 
coincidences. 

Also, since each phone line has a control circuit con- 
nection to the switch, the switch can broadcast mes- 
sages to each line using these control circuits. So, 
within a switch a truly anonymous connection can be 
established: A phone line makes an anonymous con- 
nection to some mix. That mix broadcasts a token 
identifying itself and the connection. A recipient of 
that token can make another anonymous connection 
to the specified mix, which mates the two connections 
to complete the call. 

Our goal of anonymous connections over the Inter- 
net differs from anonymous remailers and anonymous 
ISDN. The data is different, with real-time constraints 
more severe than mail, but somewhat looser than voice. 
Both HTTP and ISDN connections are bidirectional, 
but, unlike ISDN, HTTP connections are likely to be 
small requests followed by short bursts of returned 
data. As described in [10], in a local switch, capacity is 
pre-allocated to each phone line, and broadcasting is ef- 
ficient. But broadcasting over the Internet is not free, 
and defining broadcast domains is not trivial. Most 


importantly, the network topology of the Internet is 
more akin to the network topology of the long distance 
network between switches, where capacity is a shared 
resource. In anonymous ISDN, the mixes hide commu- 
nication within the local switch, but connections be- 
tween switches are not hidden. This implies that all 
calls between two businesses, each large enough to use 
an entire switch, reveal which businesses are communi- 
cating. In Onion Routing, mixing is dispersed through- 
out the Internet, which improves hiding. 

Onion Routing’s flexibility with respect to access 
configurations also make it a natural complement to 
other services like the Anonymizer [1] and Proxymate 
[ 11 ]- 

The Anonymizer is a proxy Web site that filters the 
HTTP data stream to remove a user’s identifying in- 
formation. This makes Web browsing private in the 
absence of any eavesdropping or traffic analysis. The 
Anonymizer is vulnerable in three ways: First, it must 
be trusted. Second, traffic between a browser and the 
Anonymizer is sent in the clear, so that traffic identi- 
fies the true destination of a query, and includes the 
identifying information that the Anonymizer would fil- 
ter. Third, even if the traffic between the browser and 
the Anonymizer were encrypted, traffic analysis could 
be used to match incoming (encrypted) data with out- 
going data. Onion Routing’s privacy filters provide 
a similar function to the Anonymizer. However, the 
Anonymizer’s filters are perhaps the most up-to-date of 
any readily available filters for the ever changing means 
by which anonymity can be compromised in the data 
stream. Also, the high volume that this longstanding 
service attracts provides some degree of natural cover 
traffic. An Anonymizer could be used together with 
Onion Routing as the HTTP proxy front end to pro- 
vide a nice interface and good filtering for anonymity, 
with strong resistance to both eavesdropping and traf- 
fic analysis. Security is improved because the filtering 
executes on a machine the user trusts, and communi- 
cation leaving that machine will resist traffic analysis. 
Such security in depth removes the central point of fail- 
ure for network traffic anonymity. 

Proxymate (formerly known as LPWA) is a “proxy 
server that generates consistent untraceable aliases for 
you that enable you to browse the Web, register at 
web sites and open accounts, and be ‘recognized’ upon 
returning to your accounts, all while still preserv- 
ing your privacy .” Proxymate thus provides various 
pseudonymy-based services. Like Onion Routing it is 
designed to handle email in addition to HTTP. And, 
like Onion Routing, it can be configured so that trusted 
functions are performed at various locations [2]. How- 
ever, communication between and from these points 



is not itself anonymous or resistant to traffic analysis. 
This makes Proxymate and Onion Routing especially 
natural complements. 

Pipe-net [5] is a proposal somewhat similar to Onion 
Routing. It has not been implemented, however. Pipe- 
net’s threat model is more paranoid than Onion Rout- 
ing’s: it attempts to resist active attacks by global ob- 
servers. For example, Pipe-net’s connections are per- 
manent and carry constant traffic (to resist timing sig- 
nature attacks). And, disruptions to any connection 
are propagated throughout the network. This makes 
the design impractical for any short lived or large band- 
width connections and implies that the entire network 
shuts down if even one connection does so. Thus, it 
is also highly vulnerable to denial-of-service attacks. 
Pipe-net’s design provides the strongest traffic analysis 
resistance guarantees of any given for connection-based 
communication infrastructures running over mix-like 
nodes. But, it accomplishes this at a very high price, 
so it is not likely to be implemented for large scale 
Internet use. 

Crowds [14] is roughly a distributed and chained 
Anonymizer, with encrypted links between crowd 
members. Upon receiving traffic for the first time on 
a path a crowd member flips a weighted coin, and de- 
pending on the outcome, continues the path to another 
randomly chosen crowd member or terminates the path 
and forwards this (and any future traffic on the path) 
to its ultimate destination. Crowds is less general than 
Onion Routing, both in its applications (it is designed 
only for Web traffic) and its anonymity goals (there is 
no attempt to hide the ultimate destination of traffic 
from any node on the path). 

Zero-Knowledge Systems [17] has designed a sys- 
tem with many similarities to Onion Routing. Beta 
versions are available of Freedom, their software for 
network access akin to the remote-proxy or customer- 
ISP access described above. Freedom also incorpo- 
rates local pseudonym management and other features. 
However, the currently described Zero-Knowledge sys- 
tem appears to limit routes to a fixed length of three 
hops, which makes connections much more vulnerable 
to some forms of traffic analysis [16]. Also, the system 
design does not seen to be as naturally compatible as 
Onion Routing to enclave level traffic protection, on 
either the initiator or the responder end. 

A natural extension to Onion Routing is the intro- 
duction of reply onions. Reply onions allow connec- 
tions to be made back to an anonymous sender through 
an onion routing network long after the original con- 
nection existed. Reply onions could be used to send 
anonymous replies in response to a previously received 
anonymous email. They could also enable novel ap- 


plications such as anonymous publishing (anonymous 
URLs) similar to the Rewebber project [6]. 

7 Conclusion 

In summary, Onion Routing is a traffic analysis re- 
sistant infrastructure that is easily accessible, has low 
overhead, can protect a wide variety of applications, 
and is flexible enough to adapt to various network en- 
vironments and security needs. The system is highly 
extensible, allowing for additional symmetric crypto- 
graphic algorithms, proxies, or routing algorithms with 
only minor modifications to the existing code base. In- 
structions for accessing the prototype network can be 
found on our Web page along with additional back- 
ground, pointers to publications, and contact informa- 
tion [12]. 
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